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(54) System and method for protecting use of dynamically iinl<ed executable modules 



(57) A connputer system has a program module ver- 
ifier and at least first and second program modules. 
Each program module includes a digital signature and 
an executable procedure. The first program nx)dule fur- 
thermore includes a procedure call to the second pro- 
cedure module, a procedure call to the program module 
verifier that is logically positioned in the first program 
module so as to be executed prior to execution of the 
procedure call to the second program module, and in- 
structions preventing execution of the procedure call to 
the second program module when the procedure call to 
the program module verifier results in a verification de- 
nial being returned by the program module verifier The 
second program module includes an executable proce- 
dure to be performed in response to the procedure call 



by the first program module to the second program mod- 
ule, a procedure call to the program module verifier that 
is logically positioned in the second program module so 
as to be executed prior to completion of execution of the 
second program module's executable procedure, and 
instructions preventing completion of execution of that 
executable procedure when the program module verifier 
retums a verification denial with respect to the first pro- 
gram module. The program module verifier responds to 
procedure calls by verifying the authenticity of any spec- 
ified program module and by returning a verification con- 
firmation or denial. When the program module verifier 
fails to verify the authenticity of a program module, the 
calling program module throws an exception and aborts 
its execution. 
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(54) System and method for protecting use of dynamically linked executable modules 



(57) A computer system has a program nruxlule ver- v 
ifier and at least first and second program modules:^ 
Each program module includes a digital signature and 
an executable procedure. The firstprogram module fur- 
thermore includes a procedure call to the second pro- 
cedure nrxKiule, a procedure call to the program module . 
verifier that :ls;k>gically :positioned Jn the first program ? 
module so as to be executed prior to execution !Of the < 
procedure call to the second program module, and in- 
structions preventing execution of theprocedure call to ^ 
the second program module when theprocedure call to:; 
the program rtKxiule verifier results in a verificatiori def> 
nial being returned by the program module verifier. The 
8 cond program module includes an executable proce- 
dure to be performed in response to the procedure call 



by the first progreun nfKxiule to the second program HKxJ- 
ule, a procedure call to the program module verifier that 
is logically positioned in the second program module so > 
as to be executed prior to completion of execution of the 
second program module's executable procedure, rand 
instructions preventing completion of oxecution of that 
executable procedure when the program module verifier > 
retums a verification denial with respect to the first;pror:i 
gram module. The program module verifier responds tori 
procedure calls by verifying the authenticity of any spec- 
ified program module £ind by returning a verification conn- 
::firmation or denial. -When the program module verifier 
fails to verify the authenticity of a program module, the 
calling program module throws an exception and aborts*; 
its execution. 
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The present invention relates to systems and methods for restricting the use of executable modules such that each 
executable module can be dynamically linked only to other executable modules whose authenticity has been verified. 

5 

BACKGROUND OF THE INVENTION 

In the context of a computer program, an "external function" is typically a procedure or function located in a library 
or other repository of functions that is external to the computer program using the external function. External functions 
10 ar often, but not always, authored by different people or by different entities than the computer programs using those 
external functions. 

Program execution environments that allow external functions to be bound at run time, rather than at link time or 
compile time, facilitate the maintenance and updating of computer progran^ because for such programs to be used 
In such execution environments only the computer prograrrts that are being revised or updated need to be recompiled, 

'5 while the other modules can be left unchanged. Furthermore, the recompilation process is simplified because the 
compilation of the revised programs can be performed even if other modules used by the program are not present in 
the program development system. 

However, systems using such program execution environments are vulnerable, because the interfaces between 
th program modules are usually well specified, or can be determined by third parties, and it is possible for such third 

20 parties to therefore use those program modules in ways not sanctioned by the corresponding software license agree- 
ments. Alternately such third parties can allow the system to be subverted by replacing authentic program module 
with corrupted ones. 

This problem is magnified when dealing with cryptographic routines in software that is destined for export from the 
United States of America to customers or distributors in other countries. It is currently forbidden by U.S. trade law to 

^5 export software modules that provide general cryptographic capabilities. On the other hand, it is altowed to export 
programs that use cryptographic capabilities in a limited context and that cannot be used to perfomi general crypto- 
graphic functkpns outside the limited context of the exported program. In fact, it is commercially important to be able 
to d sign software systems for export that use cryptographic functions in an authorized manner. Prior art late bound 
syst ms, such as dynamic link libraries (DLLs in the Windows system) or shared objects (.so files in Solaris), attempt 

30 to solv this problem by either obscuring the interfaces between software modules, or by providing separate "export 
only" V rsions of their software. Provkiing separate "export only" verskDns of software products leads to problems in 
keeping the domestic and export versions "synchronized* with respect to upgrades and maintenance revisions with a 
single code base. ^ 

Another example of a situatk>n where there is a need to limit or prevent use of dynamically linkable modules is an 

35 application written by a vendor that wishes to keep some functions in the application private for either trade secret or 
contractual reasons. Such systems require limiting access to these private functions. 

SUMMARY OF THE INVENTION 

w In summary, the present invention is a computer system having a program module verifier and at least first and 

second program modules. Each of the program modules includes a digital signature and an executable procedure. 
The first program module furthermore includes a procedure call to the second procedure module, a procedure call to 
the program nrKxJule verifier that is logically positioned in the first program module so as to be executed prior to executran 
of th procedure call to the second program module, and instructions preventing execution of the procedure call to the 

^ second program module when the procedure call to the program module verifier results in a verification denial being 
returned by the program module verifier 

The second program module includes an executable procedure to be performed in response to the procedure call 
by the first program module to the second program module, a procedure call to the program module verifier that is 
logically positbned in the second program nruxlule so as to be executed prior to completion of execution of the second 

•o program module's executable procedure, and instructrans preventing completkjn of execution of that executable pro- 
cedure when the program module verifier returns a verificatbn denial with respect to the first program module. 

The program module verifier responds to procedure calls by verifying the authenticity of any specified program 
module and by returning a verification confirmation or denial in response to each such procedure call. More specifically, 
in a preferred embodiment, the program verifier module includes instructions for responding to a procedure call re- 

5 qu sting verification of a specified program module by (A) decoding a digital signature in the specified program module 
with a corresponding decoding key (B) generating a message digest of at least a portion the specified program module 
in accordance with a message digest function, (C) returning a verification confirmation wh n the decoded digital sig- 
nature matches the message digest, and (D) returning a verification denial when the decoded digital signature does 
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not match the message digest. 

In the preferred embodiment, when the program module verifier fails to verify the authenticity of the second program 
module, the first program module throws an exception and aborts its execution. Similarly when the program module 
verifier fails to verify the authenticity of the first program module, the second program module throws an exception and 
s aborts its execution. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Examples of the invention will now be described in conjunction with the drawings, in which: 

10 

Fig. 1 is a block diagram of a computer system embodying the present Invention, 

Fig. 2 is a time line" representation of how a typical procedure call is performed using the preferred embodiment 
of the present invention. 

IS 

Fig. 3 is a flow chart of the method used in a preferred embodiment for two linked software nrKxJules to verify each 
other's authenticity. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 

20 

Referring to Fig. 1 , there is shown a computer system 100. While the computer 100 may be a desktop computer, 
such as a Sun workstation, IBM compatible computer, or Macintosh computer, virtually any type of computer could be 
used. The computer 100 includes a CPU 102, a user interface 104, and memory 106. Memory 106 includes primary 
random access memory (RAM) as well as secondary memory, typically one or more magnetic or optical disks. The 
2S memory 106 stores an operating system 110, a program module or object authenticity verifier 112, and a set of appli- 
cation program object Instances 114, 116, 118, 120, also called program modules or application program modules. 

As shown in Fig. 1 , in a preferred embodiment of the inventbn each application program object instance includes 
an object header 122, at least one digital signature 124, at least one embedded public encryption key 126 and a main 
application procedure 128 (often called a method). Each method or procedure 128 Includes at least one verifier pro- 
30 cedure call Instructbn 1 30 and Instructions 1 32 for responding to a verification denial message received in response 
to the verifier procedure call, such as instructions for aborting execution of the procedure. The main application A 
procedure (1 28-A) in the first program nrKxJule furthermore includes a procedure calll 34 to an executable procedure * 
(e.g., the main application B procedure 128-B) in the second procedure nrKxJule. The procedure call 130-A to the: 
program nrKxjule verifier is bgbally positioned in the first program module so as to be executed prior to executtdh of 
3S th procedure call 134 to the second program nnodule. ''^^^-'^ 
The procedure call 130-B to the program nrKKlule verifier is togteally positioned In the second program mbdule^' 
immediately after the entry point to each executable procedure 128-B in the second program module so as to be 
xecuted prrar to executbn of each such procedure 1 28-B. More generally, in other embodiments of the inventbn th 
procedure call 130-B to the program nrvodule verifier is logically positioned in the second program module (and mor 
generally, in all program modules that will be called by other program modules) prior to the completion point in each ' 

X cutable procedure in the second program nnodule so as prevent completkxi of the execution of each such procedure 
if verification of the calling program is denied by the verifier. 

In a preferred embodiment of the present invention all the procedures in a designated group, such as all the 
procedures used by a particular top level application or a suite of top level applications, have the same embedded 
^ public key 1 26 and all are digitally signed using the same private encryption key, for example using the RSA encryption 
methodology. However, in an alternate embodiment, different procedures and subgroups of procedures are signed 
with different private keys. In the alternate embodiment, the procedure modules that include procedure calls have 
embedded public keys for verification of the procedures that they can call, and all procedure modules that can be called 
by other procedures include public keys for verification of the calling procedures. 
so Fig. 2 is a time line" representation of how a typical procedure call is performed using the preferred embodiment 

of the present invention. In Fig,2 earlier events are shown at higher vertical positions than later events. Fig. 3 is a flow 
chart of the steps involved in the performance of a procedure call. 

Referring to Figs. 2 and 3, an executable procedure (e.g., the "main application A procedure' 128-A in Figure 1) 
in program module A begins execution (step 200). For the purposes of this discussion, the procedure in program 
ss module A that is being executed will be called "procedure A" and the procedure that it is attempting to call in program 
module B will be called "procedure B". 

Prior to making a procedure call to an executable procedure in program module B (step 220), procedure A makes 
a procedure call to the verifier to request verification of the authenticity of program module B (st p 202). The verifier 
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then attempts to verify the authenticity of program module B and sends a return value to procedure A to indicate whether 
or not th verification of program module 6 was successful (step 204). 

More specifically, the verifier, which is preferably a distinct trusted object (or alternately a trusted system service 
procedure) receiv s the request message from procedure A (step 206). and decodes (step 208) a digital signature 
5 embedded in program module B using a public key provided by the calling procedure (i.e., procedure A). The public 
key provided by calling procedure A to the verifier is the "group" public key 126-A embedded in program module A 

In the preferred embodiment, the digital signature of a program module is generated by computing the message 
digest of the program module, supplementing the message digest with a hash function identifier to indicate the type 
of hash function used to generate the message digest, encrypting the resulting value with a private key using the RSA 
10 encryptbn methodology, and then supplementing that encrypted value with a clear text identifier of the source (i.e.. 
author or distributor) of the program nxxJule: 

MDq = HashFunction(Program Module B) 

75 

Digital SignaturOg = Encrypt(MDQ + HashFunction ID. PrivateKey) 
+ ClearText ID of Program fy^odule B's Source 

20 Therefore to decode the digital signature of program module B, the verifier (A) renrraves the clear text ID from the 

digital signature, and then (B) decodes the remaining portion of the digital signature with the public key to generate a 
signature based message digest DS-MDg and a hash function ID. - 

25 DS-MDg + HashFunction ID 

= Decode (Digital Sign^urOg - ClearText ID. PublicKey) 

Next, the verifier computes a message digest MD^ of at least a portion of program module B (step 210) using the ^i 

30 hash function identified in the decoded digital signature. The hash function used to generate the message digest fe -^ 
typically a functioni such as a CRC encoding function, that is known to generate distinct values for distinct program . ? 
modules with extremely high probability. Many hash functtons suitable for generating a message digest 
those skilled in the art; ^ ~ : iv: 

Th verifier then compare^* the computed message digest MDg with the message digest DS-MDq in the decoded f 

35 digital signature (step 212) and retums a verificatkin confimriation message to the calling procedure (step 214) if the 
two message digests match and retums a verificatbn denial message (step 216) if the two message digests do hot 
match. ^. -V .'-I ^ 

In one preferred emtxxJiment, there is a single digital signature for each program module, and the associated ^ 
m ssage digest is computed usinga hash function of the entire contents of the program module. In other embodiments. 

40 th message digest nnay be based on only a portk>n of the program module. For instance, in a second preferred ;: 
emtKxJiment. each program module has two digital signatures: one for the methods portion of the program module and : 
another for a data portran (if any) of the program module. When a program nxxlule has two digital signatures, both of 
th message digests derived by decoding the two digital signatures must match corresponding message digests com- 
puted by the verifier in order for the verifier to return a verification confimnation message. If the message digest in either- 

45 d coded digital signature does not nnatch the corresponding message digest computed by the verifier, the verifier c 
retums a verificatk)n denial message. 

If the verifier denies verificatk)n of program nrKxJule B (step 216). procedure A throws an exception" and then ^ 
aborts (step 218). Throwing an exception generally causes the associated thread of execution to terminate and fur- 
themnore causes an exception handler procedure to be executed by the calling thread of execution so as to give the 

so calling thread of executk>n the opportunity to analyze and othenwise respond to the failure of the called procedure (i. 
e.. procedure A in this case). 

Generally, the verifier will deny verification of a program module only if the program module has been corrupted, 
such as during installation or transmission from one computer to another, or deliberately tampered with. In normal 
operatbn,. verification denials should be unusual events. 

ss If the verifier confirms verification of program nrKdule B (step 21 4). procedure A then goes ah ad with making a 

procedure call to proc dure B in program module B (step 220). In the preferred embodiment, one of the very first things 
that procedure B does upon receiving a procedur call is to mak a procedure call to the verifier (step 222). sending 
it a request to verify th authentrcity of the calling program nrKxdule (i. .. program module A in this case). 
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The verifier then attempts to verify the auth nticity of program module A and sends a retum value to procedure B 
to indicate whether or not the verification of program module A was successful (step 230). 

More specifically, the verifier receives the request message from procedure B (step 232), and decodes (step 234) 
a digital signature embedded in program module A using a public key provided by procedure B. The public key provided 
5 by procedure B to the verifier is the "group" public key 126-B embedded in program module B, 

As explained above, the digital signature of program module A is generated by computing the message digest of 
program module A, supplementing the message digest with a hash function identifier to indicate the type of hash 
function used to generate the message digest, encrypting the resulting value with a private key using the RSA encryption 
methodology, and then supplementing that encrypted value with a clear text identifier of the source (i.e.. author or 
10 distributor) of the program module: 

MD^ - HashFunction(Program Module A) 
Digital Signature^ = Encrypt(MDy^ + HashFunction ID. PrivateKey) 
+ ClearText ID of Program Module A's Source 

Therefore to decode the digital signature of program rrKxjule A. the verifier (A) renrioves the clear text ID from the 
20 digital signature, and then (B) decodes the remaining portion of the digital signature to generate a signature based 
message digest DS-MD^ and a hash function ID. 

DS-MD^ + HashFunction ID 

25 

= Decode (Digital Signature^ - ClearText ID. PublicKey) 

Next, the verifier computes a message digest MD^ of at least a portion of program module A (step 236) using th 
hash function identified In the decoded digital signature. 
30 The verifier then compares the computed message digest MD^^ with the message digest DS-MD^ in the decoded 

digital signature (step 238) and retums a verification confirmation message to the calling procedure (step 240) if the 
two message digests match and retums a verification denial message (step 242) if the two message digests do not 
mertch.. ; •. 

If the verifier denies verification of program module A (step 216). procedure B "throws an exception" and then 
35 aborts (step 244). 

If the verifier confirms verification of program module A (step 240), procedure B is executed to completion (step 
250) and the result generated by executing procedure B is retumed to procedure A (step 252). Finally, procedure A 
completes its execution using the results received from procedure B (step 254). 

40 ALTERNATE EMBODIMENTS 

In some alternate embodiments only a portk>n of the program oKxIules in a group of program modules contain 
■sensitive" algorithms or which otherwise are more important to authenticate than the other program modules. For 
instance, in a first altemate embodiment the distributor of a set of program modules (herein called the full set of program 

45 modules") might want to ensure that a small number of program nruxjules (herein called the 'restricted subset of program 
modules") in the group are used only with the other program modules in the group, but might want to allow the remaining 
program modules to be used by the licensee freely, even with program modules outside the group. In this embodiment, 
only the restrbted set of program modules include procedure calls to the verifier module. logk:alty located immediately 
after the entry points of those program modules. These entry point procedure calls to the verifier are used to verify the 

so authentteity of the calling program module, and upon verification that the calling program module is part of the authen- 
ticated group, the called program module performs the computation requested by the calling program module. 

In a second altemate emkxxiiment, the distributor of a set of program procedures is not concemed with restrbting 
the use of a set of "restrk:ted program modules," and is instead concemed that alt catling procedures attempting to use 
the services of the restrksted program modules in fact get the services of authentic versbns of the restricted program 

55 modules, in this embodiment, all procedures making procedure calls to the restrk:ted program modules include pro- 
cedure calls to the verifier modul logk^ally locat d imm diately prior to the procedure calls to the restrict d program 
modules. These verifier proc dure calls are used to verify th authenticity of the restricted program modules. However, 
in this embodiment the procedures in the restricted program modul s do not contain verifier procedure calls to authen- 
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ticate the calling program modules. Upon verification that the restricted program module to be called is authentic, the 
calling program module sends its procedure call to the authenticated restricted program module. 



Claims 

1 . A computer system comprising: 

(A) a program module verifier configured to respond to procedure calls to said program module verifier by 
verifying authenticity of any specified program module and by retuming a verification confirmation or denial in 
response to each such procedure call; 

(B) a first program module, and 

(C) a second program nnodule; 

one of said first and second program modules including a procedure call to the other of said first and second 
program modules; 

at least one of said first and second program modules including: 

a procedure call to said program module verifier to verify authenticity of the other of saki first and second 
program modules; and 

instructions for aborting execution of said one program module when said procedure call to said program 
module verifier results in a verification denial being returned by said program module verifier. 

2. The computer system of claim 1 , 

said first program module including a first digital signature and a first executable procedure; 
said second program nnodule including a second digital signature and a second executable procedure; 
said program verifier module including instructions for responding to a procedure call requesting verification 
of a specified one of said first and second program OKxIules by (A1) decoding said digital signature in said 
specified program nrxxJule with a corresponding decoding key/ (A2) generating a message digest of at least 
a portion sard specified program nrvxlule in accordance with a predefined message digest function, (A3) re- 
turning a verificatk>n confirmation when said decoded digital signature 

retuming a verification denial when said decoded digital signature does not match said message digest. 

3. Thecomputer system of claim 1, 

said first program rtKxJule including a procedure call to said second program nrK^ 
said second program module including: 

(C1 ) an executable procedure to be performed in response to said procedure call to said second pix^ram 
nrKxJule; 

(C2) a procedure call to said program module verifier logically positioned in said second jDrbgram module 
so as to be executed prior to execution of said executable procedure; and 

(C3) Instructions preventing execution of said executable procedure when said procedure call to said 
program module verifier results in a verification denial being retumed by said program module verifier 

4. Tfie computer system of claim 3, wherein said instructions preventing completion of execution of said second 

xecutable procedure include instructions for aborting execution of isaid second program nrKxiuIe when said pro- 
cedure call to said program module verifier results in a verification denial being returned by said program module 
verifier. 

5. The computer system of claim 1 , 2, 3 or 4, 
said first program module including: 

a procedure call to said second program module; 

a procedure call to said program module verifier logically positioned in said first program module so as to be 

executed prior to execution of said procedure call to said second program module; and 

instructions preventing xecution of said procedure call to said second program module when said procedure 
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call to said program modul verifier results in a verification denial being returned by said program module 
verifier. 

A method of linking program modules, comprising the steps of: 

(A) prior to making a procedure call from a first program module to a second program module, verifying said 
second program module's authenticity; 

(B) upon verifying said second program module's authenticity, making said procedure call from said first pro- 
gram module to said second program module; and 

(C) upon failing to verify said first program module's authenticity, preventing said procedure call from said first 
program module to said second program module. 

The method of claim 6, further including: 

(D) prior to completing executing a procedure in said second program module in response to said procedure 
call by said first program module, verifying said first program OKXlule's authenticity; 

(E) upon verifying said first program module's authenticity, completing executing said procedure in said second 
program module to generate a result and returning said result to said first program procedure; and 

(F) upon failing to verify said first program module's authenticity, preventing completion of execution of said 
procedure in said second program module. 

The method of claim 7, 

said step (D) including decoding said first digital signature in said first program module with a con-esponding 
decoding key, generating a message digest of at least a portion said first program module in accordance with said 
predefined message digest functfon, verifying the authenticity of said first program module when said decoded 
digital signature matches said message digest, and denying verification of the authenticity of said first program 
module when said decoded digital signature when sakJ decoded digital signature does not match said message 
digest. 

. The method of claim 6, 7 or 8. wherein step (C) includes aborting execution of said first program module. 

0. The method of claim 6, 7 or 8, wherein said first program module includes a first digital signature and said second 
program module includes a second digital signature; 

said step (A) including decoding said second digital signature in said second program module with a corre- 
sponding decoding key, generating a message digest of at least a portion said second program module in accord- 
ance with a predefined message digest functksn. verifying the authenticity of said second program module when 
said decoded digital signature matches said message digest, and denying verification of the authenticity of said 
second program module when said decoded digital signature when said decoded digital signature does not match 
said message digest. 

1. The method of claim 6, 7 or 8, 

said step (A) including making a procedure call to a trusted program module verifier, said program module 
verifier responding to said procedure call by verifying authenticity of said second program module and by returning 
a verification confirmation or denial in response to said procedure call. 
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